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(54) Process monitoring in a multiprocessing server. 

(57) A system and method for determining and 
displaying the status of client application prog- 
rams executing on a multiprocessing server. 
Server process control blocks (5) and 
synchronization object descriptors (10) are 
created in the shared memory (11) of the server 
(3). Application program interfaces APIs (8) are 
linked to the control blocks and descriptors 
during the execution of the various multip- 
rocessing application programs (7). A status 
utility (13) related to the service process moni- 
tor (12) selectively accesses information from 
the control blocks (5) and descriptors (10) to 
determine the status of the individual multiple 
processes executing on the server workstation 
(3). In a preferred form, the status information is 
conveyed to and displayed on a video display (4) 
associated with the service process monitor. In 
contrast to operating system monitors which 
disclose the status of all processes as a whole, 
the present server process monitor par- 
ticularizes the information to the specific client 
process. Thereby, the information is of a granul- 
arity to identify processes which are hung up on 
semaphores, message queues, or the like. The 
information is at the level used by a system 
administrator or software developer. 
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The present invention relates in general to sys- 
tems and methods for monitoring the activities of 
computers. More particularly, the invention is direct- 
ed to a system and method for monitoring the states 
of client application type processes executing in a 
multiprocess server of a client-server network. 

The client-server processing model has been 
widely adopted in the definition of distributed comput- 
ing type networks. In the context of such networks, 
better performance with higher degrees of service 
concurrence have been exhibited by serveroperating 
systems which execute multiple client application pro- 
grams through multiple processes. Examples are the 
OS/2® and AIX® operating system programs com- 
mercially available from IBM Corporation (OS/2 and 
AIX are registered trademarks of IBM Corporation). In 
contrast, single process operating systems require 
the server to await the completion of a current client's 
application program before commencing any aspect 
of a new client's application program. 

The present concept of multiprocessing from the 
software perspective should not be confused with 
classical multiprocessing from the hardware perspec- 
tive. From the hardware perspective, microproces- 
sors such as the Intel Corp. models 80386 and 80486 
incorporate time sharing features which accomplish 
multiprocessing through a time allocation for the dif- 
ferent instructions being processed. In contrast, mi- 
croprocessors such as the Intel Corp. model 80286 do 
not provide such a hardware capability, requiring that 
software manage any concurrent execution of multi- 
ple application programs. Operating system software 
which accomplishes this task for a 80286 type proc- 
essor, and equally for the 80386 and 80486 micropro- 
cessors, is the aforementioned OS/2 operating sys- 
tem program. The present invention is directed to 
process management in the context of such an oper- 
ating system, and not in the context of management 
by the microprocessor hardware. 

The client-server network architecture is gener- 
ally well known. With the advent of multiprocessing 
operating system capabilities in the servers, asso- 
ciating the activities occurring in the serverto specif ic 
client application program processes has proven to 
be a significant challenge not only for the user clients 
but even for network administrators. Though operat- 
ing systems, such as the aforementioned AIX pro- 
gram, provide resources for monitoring the state of a 
composite operating system on a server workstation, 
no contemporaneous information is provided about 
the states of the individual client application process- 
es executing on the server. This level of information 
is particularly important to developers of client-server 
application programs. For example, presently avail- 
able operating system monitors do not provide users 
with information regarding the server's work on a spe- 
cific application program, or why a specific applica- 
tion program is hung up, or the identity of a sema- 



phore delaying an application process. This deficien- 
cy is attributable to the fact that present operating 
system monitors do not link to the individual applica- 
tion processes, but rather, reflect the state of the com- 
5 posite of all server processes, viewed from the level 
of the operating system. Though trace log data could 
be generated in sufficient detail, the volume of the 
data requires storage to disk and time consuming 
analysis. 

10 Therefore, a need exists for a monitoring system 

which provides contemporaneous information about 
the status of individual client application processes 
undergoing execution on a multiprocessing server in 
a client-server network. 

15 Accordingly, the present invention provides a 

multiprocess server having a memory and operating 
in a client-server network and including a server proc- 
ess monitor comprising: means for creating multiple 
control blocks of the server process monitor in a part 

20 of the memory of the multiprocess server which is 
shared by the different server application processes; 
means for relating server processes to select control 
blocks; means for indicating the status of a process 
responsive to a server process monitor access of a 

25 control block. 

Thus the present invention provides a system for 
monitoring individual server processes at the granu- 
larity of the client's application program, in a selective 
and contemporaneous fashion. Information regarding 

30 the status of each client application program as re- 
flected by a server process is acquired and made 
available to the network administrator or client. In one 
form, the invention is directed to a monitoring system 
of a multiprocess server in a client- server network 

35 and comprises, a means for creating multiple control 
blocks of a server process monitor on a server proc- 
essor, means for relating server application process- 
es to control blocks in a server processor, means for 
storing the control blocks in memory shared by the 

40 different server application processes, and means for 
indicating the status of a server application process 
responsive to a server process monitor access of a 
control block. In another aspect, the invention relates 
to a method for accomplishing such application proc- 

45 ess selective monitoring. 

In a preferred form, the invention involves a ser- 
ver process monitor program for creating control 
blocks and descriptors in a shared range of a server 
workstation memory. The control blocks are linked to 

so and accessed by every server process executing a 
client application. In addition, every process running 
on the server has associated therewith synchroniza- 
tion object descriptors, defining semaphore or mes- 
sage queue states, which are similarly stored in 

55 shared memory. The control blocks and descriptors 
are registered with the server process monitor pro- 
gram upon creation and are accessed by the server 
process monitor program to derive, and subsequently 
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indicate on a video display or the like, the status of 
one or more of the server processes which are exe- 
cuting client applications. 

The server process monitorfunction can also be 
performed by an operating system deamon process, 
which deamon process periodically reads the server 
process status information from the control blocks or 
descriptors in shared memory and displays the status 
on a dedicated window of a video display. 

Irrespective of the particular form chosen, the in- 
formation provides network administrators, software 
developers or field engineers with management, per- 
formance and diagnostic information at the granular- 
ity of each client process within a complex client ser- 
ver network. 

A preferred embodiment of the invention will now 
be described, byway of example only, with reference 
to the accompanying drawings in which: 

Figure 1 is a schematic diagram depicting a client 

server network; 

Figure 2 is a schematic diagram depicting server 
processes and the server operating environment; 
Figure 3 is a schematic diagram depicting a com- 
posite flow diagram for the processes of the sys- 
tem; 

Figures 4-11 are schematics with the individual 
flow diagrams of those depicted in Figure 3; 
Figure 12 is a schematic depicting the video op- 
eration display flow diagram. 
The present invention is particularly useful in the 
context of a client-server network of the form depict- 
ed in Figure 1 . Figure 1 shows a network 1 with a num- 
ber of clients 2 and a server 3. Representative exam- 
ples of the clients 1 and servers 3 would be PS/2 or 
RISC System/6000 workstations as are commercially 
available from IBM Corporation. A representative 
choice for network 1 in the context of PS/2 worksta- 
tions would be Netbios and in such context include 
OS/2 Lan Server client code on respective worksta- 
tions 2 and OS/2 Lan Server server code executing 
on server workstation 3. These operating systems are 
also commercially available from IBM Corporation. In 
the context of the RISC System/6000 workstation im- 
plementation, a preferred choice for the network 
would be TCP/IP and accordingly include in client 2 
and server 3 workstations AIX type TCP/IP Server 
code, also commercially available from IBM Corpor- 
ation. 

Client workstations 2 transmit over network 1 re- 
quests that server 3 execute certain application pro- 
gram code responsive to commands issued by the cli- 
ent. In particular, the invention is directed to the ser- 
ver 3 executing in the multiprocessing mode of the 
aforementioned OS/2 or AIX operating systems, so 
that the various requests from the multiple clients 
timeshare the resources of server 3. The purpose of 
the server monitor is to determine and display, such 
as by way of video display 4, the status of each proc- 



ess associated with each individual application pro- 
gram invoked by a respective client. This is in contrast 
to presently available operating system monitors 
which merely describe the overall state of the server 

5 and not the states of the individual processes. Those 
differences become crucial when a client, network 
administrator, software developer or field engineer 
needs to know the specific state of a client's process, 
not only in ascertaining its momentary status, but 

10 also in identifying, when, where and in what code and 
under what conditions process execution is temporar- 
ily or permanently interrupted. 

Figure 2 schematically depicts the functional re- 
lationships between the processes and system ele- 

15 ments needed to implement the present invention. 
Serverworkstation 3 executes multitasking operating 
system code 6, a code suitable to manage by soft- 
ware processes the relatively concurrent execution of 
application program code 7 and related application 

20 processes 8 of the multiple clients 2 (Figure 1) served 
by workstation 3. The present invention provides sys- 
tems and methods for monitoring individual server 
processes at the granularity of the application pro- 
gram in contrast to the network or server operating 

25 system. Information regarding the status of individual 
server processes is acquired and made available for 
system administrator or user consideration. 

An example of a multiprocessing server applica- 
tion program for which the present server process 

30 monitor has particular relevance is the IBM Parallel 
Database Manager Server program, commercially 
available from IBM Corporation. The Parallel Data- 
base Manager Server program is composed of multi- 
ple server processes, which include a pool of data- 

35 base manager agent processes, a deadlock detector 
process, a parallel database communication process, 
client communication processes, host gateway com- 
munication processes, and high availability process- 
es. These server processes cooperate to provide the 

40 database manager service to the individual applica- 
tions invoked by the clients. The process synchroni- 
zation among the server processes is implemented 
through the process concurrence services of the 
base operating system, in this case the earlier noted 

45 OS/2 or AIX operating system. Semaphores, signals, 
and locks are examples of process concurrence ser- 
vices. The server processes also communicate 
among each other by sending information through 
shared memory or message queues. 

so These server processes can be forced into wait 
states, which states can be induced by a number of 
different reasons. For example, an agent process 
might wait for a reply message from a parallel data- 
base communication process, or fora new application 

55 request. Similarly, two agent processes might at- 
tempt to access the same database record at the 
same time, or a group of processes might be trapped 
into a deadlock situation. With so many server proo 
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esses working concurrently in the system, a system 
level, but process specific, tool to monitor the server 
processes is needed by software developers, net- 
work administrators or service engineers when diag- 
nosing malfunctions in a multiprocessing server. 5 

The present server process monitor differs from 
the operating system process monitor. The process 
monitor of the base operating system describes the 
states of each process in terms of operating system 
parameters. For instance, the "PS" command in the w 
AIX operating system causes the display of the user 
id, the process id, the parent process id, the start 
time, and the execution command of each AIX proc- 
ess. In contrast, the present server process monitor 
describes the server processes in terms of the state 15 
of each client's application process. Examples of 
valuable state information about the progress of an 
"agent" type process for the Parallel Database Man- 
ager Server are as follows: 

— in free agent queue 20 

— waiting on the database manager queue 

— waiting on the parallel database queue 

— processing database manager requests 

— processing parallel database requests 

— waiting on buffer queue services connection: 25 
token = xxxx, sid = x, 

~ waiting on closing buffer queue services con- 
nection: token = xxxx 

— waiting on buffer distribution services mes- 
sage: token = xxxx, sid = x, rid = x 30 

— waiting on buffer queue services data: token = 
xxxx, sid = x, rid = x 

— waiting on fast communication manager mem- 
ory request 

— waiting on parallel database agent shared in- 35 
formation 

— waiting on table access: table token = xxxx 

— waiting on access to data management servic- 
es database control block 

— waiting on access to data protection services 40 
database control block 

— waiting to access to data protection services 
read buffer 

~ waiting to write a log 

~ deadlock detector waiting for time out 45 

— waiting for log I/O done 

From the examples of the states identified above 
it becomes apparent that the server process monitor 
provides state particulars about each individual ser- 
ver application process in contrast to merely identify- 50 
ing the presence of an application process. 

Multiprocessing server 3 depicted in Figure 2 in- 
cludes within its memory 9 a shared memory region 
1 1 . Server process control blocks 5 and synchroniza- 
tion object descriptors/blocks 10 are defined within 55 
shared memory 11. The placement of the control 
blocks and descriptors within the shared range of the 
memory addresses ensures that all the processes are 



accessible to all of the control blocks of the process 
monitor. The common access also applies to server 
process monitor code 12, which defines a distinct ser- 
ver process status utility process 13. Control block 
and descriptor information is extracted and visually 
depicted on video display 4 by the utility process. 

A server process is described in shared memory 
11 by a server process control block. Such a block is 
created when a server process is generated and reg- 
istered with the server process monitor. The server 
process control block preferably contains four fields: 

proc_id: the process id of the server process. 

proc-type: by the nature of the server process, 
the server processes can be grouped into different 
process types. A server process can be a database 
agent process, communication process, a deadlock 
detector, et cetera. New process types can be created 
by the applications. 

proc_state: a process is either in "runnable" or 
"waiting" state. 

syn_obj_handle: the handle of the synchroniza- 
tion object which associates with the server process. 
The handle of the synchronization object is the ad- 
dress of the synchronization object descriptor. 

When a new server process type is created, a 
server process type record is also created. Each ser- 
ver process type record contains the following fields: 

proctype: the server process type identifica- 
tion. 

proc_desc: a text string that describes the func- 
tion of the server process. 

Synchronization objects such as latches, sema- 
phores, wait post areas, or message queues are de- 
scribed by synchronization object descriptors in the 
server process monitor. Each synchronization object 
descriptor preferably contains the following data 
fields: 

syn_obj_type: the types of the synchronization 
objects, including latch, wait post area, or message 
queue. 

syn_obj_id: each synchronization object type has 
its own unique identifier. Latches are identified by 
latch handles, wait post areas are identified by wait 
post area handles, and message queues are refer- 
enced to message queue descriptors. 

syn_obj_desc: a text string that describes the 
purpose of the synchronization object. 

A set of application program interfaces suitable to 
use the data structures and described above is de- 
fined through a combination of a description, pseudo- 
code, and correspondence to a flow diagram of those 
depicted in the drawings. 

The first application program interface (API) is to 
create a new server process type. 

The input is: 

proc_desc: a text string that describes the func- 
tion of the server process. 
The output is: 
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proc_type: the server process type identifica- 
tion. 

Pseudocode defining the creation of a new ser- 
ver process type is as follows: 

— create a new server process type. 

— allocate a new server process type record. 

— define the server process type identification. 
~ initialize the server process type record with 

the server process type identification and the 
server process description. 

— return the server process type identification to 
the application program caller. 

The flow diagram corresponding to the steps nec- 
essary to create a new server process type appears 
in Figure 4, which figure relates to the process com- 
posite in Figure 3. 

Aftera newserver process is created, it must reg- 
ister with the server process monitor. In that situation 
the input is: 

proc_id: the process id of the server process. 

proc_type: the server process type identifica- 
tion. 

The registration process identified as reg_svr- 
_proc has its output: ret_sta: return status. 

Pseudocode corresponding to the registration of 
a server process is as follows: 

— create a server process control block for the 
server process. 

— initialize the server process control block with 
the process id and the server process type. 

— return control to the caller of the application 
program. 

The flow diagram corresponding to the registra- 
tion of a server process appears in Figure 5, which is 
likewise a part of the composite depicted in Figure 3. 

The next application program interface (API) in- 
volves a change of the process type: chg_svr_proc. 
The change of the server process type from one to 
another involves an input of: 

— proc_id: the process id of the server process 

— proc_type: the new server process type iden- 
tification. 

The output of the application program in- 
terface is: 

~ ret_sta: return status Pseudocode for chang- 
ing a server process is as follows: 

— update the server process control block of the 
server process with the new server process 
type. 

— return control to the caller in the application 
program. 

The corresponding flow diagram is depicted in 
Figure 6 of the drawings. 

The application programming interface (API) 
reg_syn_obj registers a synchronization object such 
as a latch, semaphore, or message queue. The reg- 
istration must be accomplished before it is referenced 
by a server process. The registration involves an in- 



put of: 

~ syn_obj_type: the types of synchronization ob- 
jects can be latches, wait post areas, or mes- 
sage queues. The synchronization object type 
5 identifications are defined by the server proc- 

ess monitor. 

— syn_obj_id: each synchronization object type 
has its unique identifier. The synchronization 
object identifiers are defined by the base op- 

10 erating system when they are created. 

~ syn_obj_desc: a text string to describe the 

function of the synchronization object. 
As an output the API provides: 

-syn_obj_handle: the address of the syn- 
15 chronization object descriptor. 

Pseudocode for implementing the API is set forth 
below in correspondence to Figure 7 of the drawings. 
~ Create a synchronization object descriptor. 

— Update the synchronization object descriptor 
20 with a synchronization object type, synchroni- 
zation object id, and the synchronization object 
descriptor. 

— Return the synchronization object handle to 
the caller in the application program. 

25 Before the server process calls the base operat- 

ing system services to operate the synchronization 
object, the server process must call the wait_syn_obj 
to associate itself with the synchronization object. 
The API involves an input of: 

30 -- procjd: the process id of the server process 

— syn_obj_handle: the address of the synchroni- 
zation object descriptor. 

As an output of the API there is provided: 
-ret_sta: return status 
35 Pseudocode corresponding to the flow diagram 

in Figure 8 of the drawings is set forth below: 

~ use the process id of the server process to lo- 
cate the server process control block. 
~ change the process state of the server process 
40 control block from the: "runnable" to the "wait- 

ing" state. 

— update the synchronization object handle of 
the server process control block. 

— return control to the caller in the application 
45 program. 

When the server process returns from the exe- 
cuting operations on the synchronization object, the 
server process calls run_svr_proc to change the ser- 
ver process state from "waiting" to "runnable". 
so The input is: 

~proc_id: the process id of the server process. 
The output is: 

~ret_sta: return status. 
The corresponding pseudocode, is depicted by 
55 flow diagram in Figure 9, involves the follows: 

— Change the server process from "waiting" to 
"runnable" in its server process control block. 

~ Return control to the caller in the application 
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program. 

A server process can be deregistered with the 
server process monitor by calling the dereg_svr_proc 
API. The server process control block of the server 
process will thereupon be freed. When a server proc- 
ess is terminated, by convention or otherwise, the 
server process exit routine calls dereg_svr_proc to 
deregister it from the server process monitor. The in- 
put to the API is: 

— proc_id: the process id of the server process. 

The output is: 
~ret_sta: return status. 

Pseudocode corresponding to the flow diagram 
in Figure 10 is as follows: 

— free the server process control block of the 
server process. 

— return control to the caller in the application 
program. 

A synchronization object is deregistered from the 
server process monitor by calling an API identified as 
dereg_syb_obj. The syn_obj_type in the synchroni- 
zation object in descriptor is changed to invalid_obj. 
The corresponding syn_obj_id in the synchronization 
object descriptor is changed to zero. The syn_obj- 
_desc in the corresponding synchronization object 
descriptor is changed to a null string pointer. 

The input to the API is: 

— synobjhandle: the address of the syn- 
chronization object descriptor. 

The output the of the API is: 
-ret_sta: return status. 

The flow diagram for this API appears in Figure 
11 and corresponds to the following pseudocode: 

— change syn_obj_type in the synchronization 
object descriptor to invalid_obj. 

— change syn_obj_id in the synchronization ob- 
ject descriptor to zero. 

— change syn_obj_desc in the synchronization 
object descriptor to no. 

~ return control to the caller in the application 
program. 

An API utility suitable to convey server process 
status information to the video display, such as video 
display 4 in Figure 2, is presented by flow diagram in 
Figure 1 2. The server process status utility can be is- 
sued from any window of the base operating system. 
The utility spawns a process, process 13 in Figure 2, 
which has read access to the server process monitor 
residing in shared memory 11 of server workstation 
3, as depicted in Figure 2. The utility reads the server 
process control block and synchronization object de- 
scriptor information and provides that information to 
video display terminal 4 in the format selected by the 
user. In a preferred form, the utility provides the user 
with options for selecting the server process status by 
process type, process state or the process id. 

The utility includes resources for interpreting the 
synchronization object descriptor on which a process 



is waiting in those situations where the server proc- 
ess is in a waiting state. 

Pseudocode to display the server process status, 
corresponding to the flow diagram in Figure 12, is set 
5 forth as follows: 

— read all the server process control blocks. 
-- if the server is runable. 

— display the server process status. 
~ else. 

w — read the synchronization object descriptor. 

-- endif. 

~ return control to the caller in the server proc- 
ess status program. 
Though the invention has been described and il- 
ls lustrated by way of a specific embodiment, the meth- 
od and systems encompassed by the invention 
should be interpreted consistent with the breadth of 
the claims set forth hereinafter. 



Claims 

1. A multiprocess server having a memory and op- 
erating in a client- server network and including 

25 a server process monitor comprising: 

means for creating multiple control blocks 
of the server process monitor in a part of the 
memory of the multiprocess server which is 
shared by the different server application proc- 

means for relating server processes to se- 
lect control blocks; 

means for indicating the status of a proc- 
ess responsive to a server process monitor ac- 
35 cess of a control block. 

2. A server as claimed in claim 1, wherein the 
means for indicating the status of a server proc- 
ess comprises: 

40 means for displaying the state of a server 

process using information from a control block 
accessed by the server process monitor. 

3. A server as claimed in claim 1 or claim 2, further 
45 comprising: 

means for registering a server process 
with the server process monitor upon creation of 
the server process in the multiprocess server. 

so 4. A server as claimed in any preceding claim, fur- 
ther comprising: 

means for relating synchronization objects 
of the server processes to descriptors accessible 
by the server process monitor. 

55 

5. A server as claimed in claim 4, further compris- 
ing: 

means for registering a synchronization 
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object with the server process monitor upon cre- 
ation of the synchronization object in the multi- 
process server. 

6. A method of operating a server process monitor 5 
of a multiprocess server having a memory and 
operating in a client-server network, comprising 

the steps of: 

creating multiple control blocks of the ser- 
ver process monitor in a part of the memory of the 10 
multiprocess server which is shared by the differ- 
ent server application processes; 

relating server processes to select control 
blocks; and 

indicating the status of a server process 15 
responsive to a server process monitor access of 
a control block. 

7. A method as claimed in claim 6, wherein the step 

of indicating the status of a server process com- 20 
prises: 

displaying the state of a server process us- 
ing information from a control block accessed by 
the server process monitor. 

25 

8. Amethod as claimed in claim 6 or claim 7, further 
comprising the step of: 

registering a server process with the ser- 
ver process monitor upon creation of the server 
process in the multiprocess server. 30 

9. A method as claimed in any of claims 6 to 8, fur- 
ther comprising the step of: 

relating synchronization objects of server 
processes to descriptors accessible by the server 35 
process monitor. 

10. Amethod as claimed in claim 9, further compris- 
ing: registering a synchronization object with the 
server process monitor upon creation of the syn- 40 
chronization object in the multiprocess server. 
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